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uring  the  past  20  years,  there  has  been  an  increasingly  more  obvious  need 

Dto  maintain  system-level  documentation  in  a  common  digital  data  environ¬ 
ment.  A  common  data  environment  will  enable  much  more  consistency  in 
the  data  contained  within  the  numerous  technical  documents  associated 
with  today's  complex  weapons  systems.  That  is  because  there  are  numer¬ 
ous  inconsistencies  in  nearly  all  of  the  technical  documents  of  the  modern  weapons 
systems  in  use  today. 
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A  typical  DoD  weapons  system  contains  technical  manu¬ 
als,  planned  maintenance  system  (PMS)  maintenance  re¬ 
quirement  cards  (MRCs),  maintenance  and  operator  train¬ 
ing  course  materials,  parts  lists,  and  so  on.  The  technical 
information  contained  within  those  documents  is  typically 
developed  with  a  variety  of  software  products.  For  example, 
most  technical  manuals  were  typically  created  in  Adobe® 
FrameMaker,  or  Microsoft®  Word,  while  PMS  MRCs  were 
developed  in  Standard  Generalized  Markup  Language.  The 
format  of  the  data  in  a  variety  of  technical  and  logistics  docu¬ 
mentation  associated  with  a  system  can  easily  exceed  30  to 
40  unique  and  separate  data  formats  created  by  different 
software  systems.  The  large  variance  of  software  programs 
can  lead  to  numerous  problems  with  skill  level,  expertise, 
licensing,  compatibility,  storage,  etc.,  as  well  as  result  in  in¬ 
consistent  and  unreliable  technical  data  across  the  various 
documents.  That  significantly  increases  the  amount  of  work 
required  to  research  technical  issues  and  costs  the  govern¬ 
ment  a  great  deal  of  money  each  year. 

Furthermore,  when  the  weapons  system  is  initially  devel¬ 
oped,  all  of  the  technical  documentation  appears  to  contain 
identical  information,  but  in  reality,  there  are  slight  differ¬ 
ences.  This  variation  in  documentation  is  a  result  of  several 
factors:  different  personnel  developing  different  documents, 
different  software  tools,  etc.  Content  variation  can  result  in 
potentially  serious  conflicts  in  the  technical  data  supplied  to 
the  warfighter  and  can  result  in  numerous  manhours  wasted 
researching  incorrect  or  inconsistent  technical  information, 
not  to  mention  the  potentially  serious  consequences  of  in¬ 
consistency  in  safety-related  issues. 
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Modified  Waterfall  Incremental  Build  Model 


Build  1  Build  2  Build  3 


Database  Reports  Web  Access 


As  the  weapons  system  is  supplied  to  the  field,  several  differ¬ 
ent  personnel  will  maintain  the  technical  documentation  in 
their  native  formats.  As  changes  occur  and  are  incorporated 
into  the  system  or  technical  specification  data  is  updated, 
the  entirety  of  the  technical  documentation  is  not  always 
corrected.  Therefore,  the  technical  documents  often  diverge 
further  and  further  from  each  other.  A  quick  look  into  the 
systems  part  ordering  information  will  clearly  illustrate  the 
problem.  Parts  information  is  usually  maintained  in  the  tech¬ 
nical  manuals,  PMS  MRCs,  allowance  parts  list,  weapons 
systems  file,  training  course  material,  user's  logistics  support 
summary,  etc.;  and  a  surprising  amount  of  data  variation 
currently  exists  in  those  documents.  The  variation  is  partly 
because  technical  personnel  do  not  change  the  information 
in  all  related  technical  documents.  Some  of  the  documents 
had  variations  from  the  start,  requiring  quick  and  efficient 
data  comparison  between  the  various  formats.  All  of  that 
results  in  a  potentially  dangerous  situation  of  inconsistent 
data  for  the  warfighter.  A  more  efficient  manner  of  techni¬ 
cal  data  management  is  required  to  ensure  all  of  a  system's 
technical  data  is  as  consistent  and  maintainable  as  possible. 

Conversion  to  Digital 

The  DoD  Policy  for  Transition  to  a  Digital  Environment  man¬ 
dates  a  DoD  digital  environment  by  the  end  of  2002.  This 
started  on  July  2, 1997,  when  Deputy  Secretary  of  Defense 
John  P.  White  signed  the  “Policy  for  the  Transition  to  a  Digital 
Environment  for  Acquisition  Programs.''  The  policy  directed 
DoD  program  managers  to  establish  data  management 
systems  and  digital  environments  that  allow  every  activ¬ 
ity  involved  with  a  program  throughout  its  total  life  cycle 
to  exchange  data  digitally.  One  of  the  essential  and  most 
data-intensive  elements  of  the  logistics  portion  of  this  digital 
environment  is  product  data.  Product  data  is  the  technical 
and  management  data  required  to  field,  operate,  and  sup¬ 


port  DoD  weapons  systems.  Where  are  your  programs  at 
with  accomplishing  the  intent  of  the  digital  data  directive? 

Taking  the  DoD  digital  policy  to  heart,  a  much  more  efficient 
method  of  developing  and  maintaining  weapons  system 
technical  data  is  possible  if  all  documents  are  developed  in 
a  common  data  environment.  In  such  a  data  environment, 
technical  data  is  easily  stored,  maintained,  upgraded,  and 
changed  as  required.  When  a  technical  change  is  made  to 
the  data  within  the  data  store,  all  of  the  references  to  that 
data  are  also  changed.  Such  an  environment  can  be  effi¬ 
ciently  created  with  any  of  the  various  database/data  store 
tools  commonly  in  use  today  such  as  Oracle®,  Sybase®,  etc. 

With  the  off-the-shelf  report  generation  tools  available  with 
most  of  the  larger  database  systems,  reports  can  be  gen¬ 
erated  to  provide  the  functionality  as  well  as  the  look  and 
feel  of  existing  technical  manuals,  training  course  material, 
PMS  MRCs,  parts  lists,  etc.  Since  the  core  data  comes  from 
the  same  source— i.e.,  the  common  data  environment— the 
data  is  fully  consistent.  Any  required  changes  to  existing  data 
will  be  properly  reflected  in  all  documentation  immediately 
upon  incorporation  of  the  change  in  the  master  database/ 
data  store.  Users/maintainers  can  easily  access  the  data  via 
a  Web  interface.  Since  security  is  an  issue  in  DoD  weapon 
systems,  extensive  efforts  in  the  areas  of  encryption/de¬ 
cryption  can  be  applied  to  the  data,  and  user  access  control 
and  safeguards  can  be  incorporated  to  prevent  unauthorized 
disclosure  of  the  data. 

Systems  Engineering  Process 

To  develop  an  integrated  data  management  system  in  the 
most  efficient  manner,  a  modified  waterfall  incremental 
build  model,  such  as  that  depicted  in  the  figure  on  this  page, 
should  be  used.  The  actual  steps  in  each  block  will  be  refined 
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On  July  2, 1 997,  Deputy  Secretary  of  Defense  John  P.  White  signed 
the  "Policy  for  the  Transition  to  a  Digital  Environment  for  Acquisition 
Programs.”  The  policy  directed  DoD  program  managers  to  establish 
data  management  systems  and  digital  environments  that  allow  every 
activity  involved  with  a  program  throughout  its  total  life  cycle  to 
exchange  data  digitally. 


based  on  input  and  consultation  with  database/data  stores 
and  system  technical  experts. 

Although  the  principles  of  systems  engineering  are  typically 
applied  only  to  a  hardware  development  program  and  not  to 
a  software  intensive  development,  there  are  many  benefits 
to  applying  a  formal  systems  engineering  process  to  any 
system  development.  Systems  engineering  principles  and 
methods  would  be  applied  to  all  aspects  of  the  management 
and  engineering  development  phases  during  the  develop¬ 
ment  of  the  project. 

The  first  step  in  accomplishing  such  a  data  management 
system  would  be  to  perform  a  requirements  analysis  based 
on  the  needs  and  inputs  from  users  as  well  as  engineering, 
logistics,  and  system  managers;  and  then  accomplish  inter¬ 
face  definition  and  control,  overall  system  trade  studies  with 
sensitivity  analysis,  and  concept  definition  and  exploration. 
At  that  point,  the  system  would  start  to  develop  into  a  po¬ 
tentially  useful  product,  at  least  from  a  conceptual  point  of 
view.  The  next  application  of  systems  engineering  would  be 
in  the  design  and  integration  stage,  where  the  project  would 
start  to  resemble  a  real  system. 

The  system  development  should  be  accomplished  in  units, 
which  are  typically  the  lowest  software  unit  and  contain  ap¬ 
proximately  100-200  lines  of  code.  The  units  are  then  com¬ 
bined  and  become  part  of  the  functional  modules.  Those 
units  and  modules  would  significantly  simplify  the  manage¬ 
ment  of  the  project  and  enable  more  efficient  debugging  of 
any  problems  or  abnormalities  that  may  be  encountered  in 
the  software  coding  portion  of  the  design.  After  each  unit  is 
properly  coded,  the  unit  would  be  tested  with  other  related 
units  to  ensure  unit-to-unit  functionality.  This  unit  and  mod¬ 
ule  level  management/testing  of  the  project  will  enable  ef¬ 


ficient  peer  review  of  software  units  and  proper  functionality 
of  the  modules  that  are  developed. 

After  all  of  the  functional  units  and  modules  are  developed, 
full  integration  development  would  occur.  Since  this  is  a 
modified  waterfall  incremental  build,  the  software  design 
and  development  will  be  developed  in  phases  that  allow  in¬ 
creasing  levels  of  capability  to  be  fielded  in  a  shorter  period 
of  time  compared  to  a  serial  development  process.  Unit- 
to-unit  integration  would  naturally  lead  into  full  integration 
testing  to  ensure  all  of  the  system  requirements  are  fully  met 
by  the  design  and  also  to  ensure  the  overall  system  performs 
as  designed. 

An  Efficient  System 

The  systems  engineering  concept  for  an  integrated  data 
management  system  will  enable  the  warfighter  to  operate 
and  perform  maintenance  on  deployed  systems  in  a  much 
more  effective  and  efficient  manner.  DoD  personnel  would 
trust  the  data  more  and  would  be  more  likely  to  provide 
meaningful  input  for  improvements  to  the  data  as  well  as 
the  integrated  data  management  system  tool.  It  is  my  desire 
that  this  article  will  enable  more  thorough  research  into  the 
premise  of  integrated  data  environments  as  well  as  provide 
sufficient  formalization  of  the  concept  to  the  point  required 
to  actually  obtain  funding  to  implement  this  type  of  system 
as  a  proof  of  concept.  This  system  would  not  only  help  the 
warfighter  but  also  help  the  engineering,  logistics,  and  pro¬ 
gram  management  personnel  as  well. 


The  author  welcomes  comments  and  questions  and  can  be 
contacted  at  james.m.young@navy.mil. 
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